home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / doc / www-talk.archive.Z / www-talk.archive / text0331.txt < prev    next >
Encoding:
Text File  |  1992-11-30  |  4.5 KB  |  108 lines
  1.  
  2. >How about above instead of
  3. >
  4. >> <dd><a HREF="wais://quake.think.com/INFO" INDEX=1>search</a>
  5. >
  6. >using
  7. >
  8. >> <dd><a HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>search</a>
  9.  
  10. Sure... I don't have any strong opinions about the syntax, except that
  11. RELATIONSHIP is longer than 8 characters, and that will be an issue
  12. with some SGML parsers.
  13.  
  14. This opens up the discussion of link semantics from a while ago. Some
  15. folks suggested a TYPE or ACTION or RELATIONSHIP attribute on anchors:
  16.  
  17. SEE    (the default) see HREF, i.e. this anchor refers to HREF
  18. INCLUDE    include HREF at this point in the document (for quoting)
  19. REPLACE    replace the anchor text with HREF (another quoting mechanism)
  20. AUGMENT    display HREF along with this document (for figures, etc.)
  21. SEARCH    search HREF and display the results
  22.  
  23. You could have zillions of options here: DEFINE (HREF defines this anchor),
  24. UPDATE (HREF is a new version of this document), TRANSLATE (HREF is
  25. some converted form of this document). But I suggest we call the attribute
  26. ACTION, and only create a new one when there is a user-interface impact.
  27. So the ACTION attribute is a hint from the author on how to display
  28. the document. That way, all the DEFINE, UPDATE, TRANSLATE, etc fall under
  29. SEE above.
  30.  
  31. >The argument for the W3 model is that often the user will want to search
  32. >or not search a single index, and he doesn't want two operations: one to
  33. >select the fact that he wants to search (click) and one to search
  34. >(typetypetyepe return).  He just wants one.
  35.  
  36. But in practice, it's the same: if I quote a wais source from this
  37. mail message, you'll have to 1) traverse the link to the index,
  38. and 2) search the index.
  39.  
  40.  
  41. >   After all,
  42. >if he clicks on a gopher index link, what does he get? a serach panel.
  43. >And what is the difference between that and a serachable document?
  44. >Only speed of display. If the serachable document can come up as fast as
  45. >a search panel, then there is no contest. If not, there is.
  46. >
  47. >In the long term the search will become (if my philosophising of
  48. >the oher day comes true) an instance of a class of search query, for which
  49. >an editor will exist if the client supports it. So searches with
  50. >toggle buttons and radio buttons and stuff will be possible,
  51. >and a gopher serach and W3 search will be subclasses.
  52.  
  53. [Ever seen Dynatext? It supports query dialogs of this sort...]
  54.  
  55. Ah... this is a perspective that I hadn't thought of: that the
  56. gopher search panel is analagous to the WWW index "cover page."
  57.  
  58. I was thinking of a model where in stead of a link from document X
  59. to index Y and then another to search results document Z, the link goes
  60. from X to Z, and searching the index is part of traversing the link.
  61.  
  62. It makes sense to me to have the links mirror protocol transactions.
  63. In other words, if we have a two step protocol:
  64.  
  65. client: "I want to do a search."
  66. server: "OK... here's the query form."
  67. client: "Here's the filled-out query form."
  68. server: "OK... here are the results."
  69.  
  70. Then the WWW model of "searchable documents" (query forms) makes sense.
  71.  
  72. But currently, we just have one step protocols:
  73.  
  74. client: "I want to do a search. Here's what I'm interested in..."
  75. server: "OK... here are the results..."
  76.  
  77. So as long as the client can do all the preparation for the query
  78. without help from the server, we should not penalize users with an
  79. extra network round trip.
  80.  
  81. I don't think the network will ever be a non-issue.
  82.  
  83. >An important addition is just a document-wide
  84. ><LINK HREF="wais://quake.think.com/INFO" RELATIONSHIP=SEARCHME>
  85. >empty element which makes a document searchable, directing seraches
  86. >to a given index. Similarly  RELATIONSHIP=GLOSSARY would
  87. >allow double-clicked words to be looked up in a remote glossary.
  88. >
  89. >This would solve the problem with WAIS source files, in that their hypertext
  90. >representation would have such a link to the index, so the source file itself
  91. >appears searchable. There are lots of places where this would be neat.
  92.  
  93. Sure... we need to treat <ISINDEX> as shorthand for
  94. <A NAME="k" HREF=_this_document_ ACTION=SEARCH></a>
  95.  
  96. As for making it global to the document, you could just treat the
  97. first SEARCH anchor as the default index to search. In the linemode
  98. browser, you could type "k words" to search the default index,
  99. or "7 k words" to search the index assocated with anchor 7. In a GUI
  100. browser, you could have a search text area, and a search button. The
  101. search button would be inactive unless there are SEARCH anchors. Then
  102. it would default to the first one, and clicking any other SEARCH anchor
  103. would just "steer" the search button towards that index.
  104.  
  105. Dan
  106.  
  107.  
  108.